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SPECIFICATION 
DATABASE SYSTEM INCLUDING HIERARCHICAL LINK TABLE 
BACKGROUND OF THE INVENTION 

Field of the Invention 

5 The present invention relates to a database system that is 
accessed by an application program that executes a 
specific operation, and relates in particular to a 
database system that can flexibly cope with an addition to 
or a change in the application contents or in 
10 relationships among data. 

Description of the Related Art 

Since an application program that executes a specific 
operation handles a large amount of data, normally, such 
data are stored and managed by a database system. This 

15 database system is generally constructed as follows. 

First, databases (also called entities) required for all 
the application programs, and data entries for the 
pertinent databases (also called attributes of the 
individual entities) are obtained. Then, the relationship 

20 between the databases (the hierarchical structure, such as 
a parent-child relationship) and the relationship between 
the data entries for each database are defined or 
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determined, so that processing can be efficiently 
performed by all possible application programs. These 
relationships that are determined can be represented as an 
ER diagram (Entity Relationship diagram) . An ER diagram 
5 is defined as an actual database for which the function of 
a database management system (DBMS) is used. For example, 
a relational database is defined using a language such as 
SQL . As a result, in each database, relationship data 
(e.g., a pointer) pointing to a record identifier for a 
10 related database is generated in a record (a key area or a 
column) in which the actual values and the contents 
(instances) of individual data are stored. Actually, the 
relationship data (e.g., pointers) tend to be generated by 
an application program as a part of a normal application. 

15 When the contents of an application are changed or a new 
application is added, or when a database is added or 
changed, the relationship/hierarchical structure of the 
databases is modified accordingly (for example, the 
parent-child relationship is canceled/added/reversed) . In 

20 this case, an alteration operation must be performed by 
which the databases are again related with each other in 
the above described manner, and the obtained hierarchical 
structure is stored in a database using the function for 
the database management system (DBMS) . Further, 

25 relationship data, such as pointers, that are present in a 
record (column) in each conventional database must be 
changed. Specifically, a program for changing the 
database is prepared, and is then used to alter the 
database . 
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When such a change is made, all the application programs 
that employ the modified database (which read and process 
data entries, or which write and update data) must be 
examined to confirm that the contents have been changed in 
5 accordance with the hierarchical structure of the 

database, and that the modification has had no adverse 
affect. As a part of a normal application, a process 
could be performed by which, while there is no change in 
the relationship of the databases, i.e., in the database 

10 hierarchical structure, the relationship of a record in a 
database to a record in another related database would be 
changed (e.g., a parent-child relationship or a positional 
relationship is modified at a so-called instance level, 
such as a case wherein a client A gives a specific 

15 telephone number to another person) . An application 
program will handle this change process. 

For a specific application program, the relationship and 
the hierarchical structure required for the processing are 
present in a group of databases that are employed by the 
20 program. Since this relationship/hierarchical structure 

constitutes a part (a subset) of the relationship existing 
among all the databases, a different 

relationship/hierarchical structure for the pertinent 
application program need not be prepared. That is, by 
25 navigating through those relationship data, such as 

pointers, that represent the relationship among all the 
databases, a required database can be reached. However, 
while taking working efficiency into account, the 
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relationship/hierarchical structure of a pertinent 
application program is normally prepared using a function 
of the database management system (DBMS) called the view 
function. Using this function, an application program can 
5 access a pertinent database group by referring to the 
view. 

When an operational database used for applications is 
viewed in another way, generally, the actual 
value/contents (instances) of the latest data are stored 

10 in individual records in each database, and only the 

latest data can be employed. The "latest" here is a value 
(results of a nighttime batch process) obtained when a 
nighttime process was completed for the preceding day, or 
the latest state (results of a real time process) obtained 

15 by adding/updating data each time a transaction occurs. 
When an application program performs a process for each 
specific period, for example, when an application program 
totals at the end of a month the records stored during 
that month, the pertinent application program accesses the 

20 database at the end of the pertinent month and performs a 
predetermined process based on all the latest data records 
that are stored in the database. However, a case exists 
wherein the relationship among databases or data records 
is changed at a specific time in the middle of a month 

25 (e.g., a case wherein the parent-child relationship (or 

belonging relationship) is changed at a so-called instance 
level, such as when client A gives (actually, sells) a 
specific telephone number to another person) . In this 
case, data representing the period during which the 
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pertinent relationship was effective are not included in 
conventional relationship data (e.g., a pointer). As a 
result, when the change of the relationship occurs, the 
pertinent application program must be temporarily 
5 initiated based on the latest recorded data and the 

relationship data, and at the end of the month in which 
the relationship was changed, that application program 
must again be executed based on the latest recorded data, 
i.e., the changed data and the relationship data. 

10 Problems to be Solved by the Invention 

However, for the above database construction method, it is 
extremely difficult and takes a very long time for the 
relationships among all the databases that all the assumed 
application programs require to be searched for in 

15 advance, and to be defined and determined. Actually, 
therefore, the relationships are defined or determined 
while being compromised, to a degree. Thus, later, the 
relationships among the databases must be changed 
frequently, and accordingly, for the application programs, 

20 many changes and many tests must be performed and the 

expenditure of an enormous amount of time and effort is 
required. The hierarchical structure that is prepared by 
the view function of the database management system (DBMS) 
is nothing more than a subset of the overall hierarchical 

25 structure, and does not constitute the main body of the 
database. Therefore, the view-based hierarchical 
structure can not be independently changed, and the same 
problem as described above will arise. 
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This means that a database system can not be provided that 
can flexibly and quickly cope with the addition of a new 
application or a change in the contents of a conventional 
application. That is, even when a new application status 
5 develops that has a new database relationship/hierarchical 
structure (for example, when, to win out over competition, 
a new product or service is provided that has a database 
parent-child/grouping relationship that differs from a 
conventional one) , a database system can not be quickly 

10 updated. Further, when a database parent-child 

relationship that is required for a specific application 
program is the reverse of a database parent-child 
relationship that is required for another application 
program, or when a database parent-child relationship is 

15 to be reversed because the status of an application has 
changed, occasionally the hierarchical structure of the 
database can not be defined, and such an application 
status can not be implemented. Or consider a situation 
wherein although an application program was specifically 

20 designed to process a certain reference database (parent 
entity) and a group of databases (child entities) that 
depend from it, another entity is added at an upper level 
(a grand-parent level) , higher than that of the original 
reference database (parent entity), and following this, 

25 the processing of the databases have to be based on the 
new grand-parent entity (e.g., a case wherein when a 
"company" is acquired by a "holding company," an 
application program that was designed to perform charge or 
discount processing while using as a reference unit an 
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upper entity comprising the "company, " thereafter is 
required to perform the same processing while using as a 
reference unit an upper entity comprising the "holding 
company"). For this, all the databases and the 
5 relationship data, and the associated application program 
would have to be drastically changed, and actually, in 
many cases such a change is not even attempted. Further, 
the same problem occurs when, in the above example, the 
data records (instances) of the two reference databases 
10 (entities) must be combined to form a single database 

(e.g., two companies are merged into a single company). 

In other circumstances, another, different problem has 
arisen. In an application program for performing a 
process at intervals corresponding to a specific time 

15 period, when the data records in the databases, or the 

relationships of the databases, must be changed during the 
course of such a time period, the above described 
complicated process for executing the program is required. 
Generally, merely the data contents that correspond to a 

20 specific time, the latest, whereat the database was used 

by the application are maintained. Therefore, the program 
execution process is required because a retroactive 
process can not be performed, even though the database has 
been accessed. In this case, the program must be executed 

25 each time a database change is required, or when a stored 
file that contains historical data (e.g., a log file) must 
be read and a special process performed. Thus, since a 
function for such a special process must be prepared for 
the application program, this results in an increase in 
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the complexity and size of the program and in a 
deterioration in its quality, and in an increase in the 
program development and maintenance costs. 

Since, as is described above, *the hierarchical structure 
5 that is constructed by using the database management 

system (DBMS) function, called the view, is not the main 
body of- the database, the effective time data required by 
the application can not be arbitrarily established, and 
the above problems can not therefore be resolved. 

10 SUMMARY OF THE INVENTION 

It is one object of the present invention to resolve the 
above described problem, i.e., a problem that prevents a 
conventional database system from flexibly and quickly 
cope with a change in the contents of an application, or a 

15 change in the contents or the relationships of databases. 
Therefore, the present invention provides a database 
management system whereby the relationships of databases 
(entities) can be flexibly established or changed without 
a great work load being imposed on the 

20 development/maintenance of the databases or an application 
program, and a database management system that can 
independently handle a period for processing databases by 
using an application program and a period for adding or 
changing the relationships of the databases or for adding 

25 or changing data records (instances), while obtaining 

flexibility along the same time axis (the elapse of time) 
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by improving mutual dependency. Therefore, a database 
system that can be altered flexibly can be provided. 

Specifically, according to the present invention, data 
(pointers, etc.) for the relationship of databases, called 
5 "hierarchical node databases, " are in principle not 
included in the individual databases (and their data 
records) that are to be processed. Tables (a type of 
database), called "hierarchical link tables," in which 
relationship data for the database (entities) are mainly 
10 entered, are prepared that correspond to the individual 

application programs, which can refer to the corresponding 
hierarchical link tables to access desired hierarchical 
node databases . 

One part of the relationship data may be included in the 
15 hierarchical node databases for the reason that a 

hierarchical link table that is destroyed for a specific 
cause can thus be recovered via another route. 

According to the database management system of this 
invention, databases that are required by all the assumed 

20 application programs need neither be searched for in 

advance nor be defined or determined. Instead, only the 
databases that currently seem to be necessary need be 
listed in the hierarchical link table to satisfy requests 
made for application programs. When an application 

25 program is added in accordance with a new request, a 
corresponding alteration must be reflected in the 
hierarchical link table. Further, when the parent-child 
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relationship of the databases that is required by a 
specific application program is the reverse of the 
parent-child relationship that is required for another 
application program, or when the parent-child relationship 
5 is to be reversed because a new application request has 
been added, the hierarchical node databases in which data 
are stored need not be changed, and only the parent-child 
relationship or the hierarchical structure must be defined 
that is required for the hierarchical link tables that 

10 correspond to the application programs. The same process 
can be performed in a case wherein a specific reference 
database (entity) must be added or modified (see the above 
"holding company" example) , or a case wherein the data 
records (instances) of two reference databases (entities) 

15 are combined (see the above merging of companies example) . 

The individual data records in each hierarchical link 
table are comparatively short, and only the relationship 
data (a pointer, etc.) and, as needed, effective period 
data that will be described later are stored therein. 

20 Thus, the hierarchical link table can be easily changed 
within a short period of time, even when data have been 
backed up to prepare for the occurrence of a malfunction. 
Further, since only one, or an extremely small number, of 
the corresponding application programs are adversely 

25 affected by such a change, a comparatively small amount of 
labor is required to perform a confirmation test after the 
change . 
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Furthermore, according to the present invention, a period 
can be established during which a parent-child 
relationship or a hierarchical node database (data record) 
hierarchical structure, which is stored as pointer data in 
5 a data record, is effective for a corresponding 

application program, i.e., an effective date (effective 
start date) and an ineffective date (effective end date) 
can be established for the individual data records of a 
hierarchical link table. Data for an effective start date 
10 and an effective end date are collectively called 

effective period data. When effective period data are 
included, application programs can individually perform 
processes retroactively. 

The effective period data may or may not be established in 
15 the hierarchical node databases. Since a hierarchical 

node database is generally accessed in common by various 
application programs, an effective date for all the 
application programs that access the databases may be 
established, or either a plurality of effective dates or 
20 no effective dates may be established for the primary 

application programs. When an effective period is to be 
established for only a specific application program, the 
effective period data in the hierarchical link table need 
only be adjusted, and such data do not have to be stored 
25 in the hierarchical node databases. 

To conclude the above explanation, according to the 
present invention, a database system comprises: 
hierarchical node databases, in which data that are used 
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by application programs that execute a specific operation 
are stored as node data in data records; and hierarchical 
link tables, one of which is provided for each of said 
application programs, wherein relationship data, which 
5 define the hierarchical structure of node data that are 
stored in the hierarchical node databases, are entered as 
data entries in the data records. Furthermore, effective 
period data, which define effective periods for the data 
records, are stored as data entries in data records in the 
10 hierarchical link tables, but may also be stored in the 
hierarchical node databases. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the 
invention are set forth in the appended claims. The 

15 invention itself, however, as well as a preferred mode of 
use, further objects and advantages thereof, will best be 
understood by reference to the following detailed 
description of an illustrative detailed embodiment and 
when read in conjunction with the accompanying drawings, 

20 wherein: 

Fig. 1 is a block diagram for explaining a data 
processing system according to the present invention. 

Fig. 2 is a diagram for explaining the conventional 
relationship of databases (entities) . 
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Fig. 3 is a diagram for explaining database relationships 
using a hierarchical link table according to the present 
invention . 

Fig. 4 is a diagram for explaining the hierarchical link 
5 table system of this invention, while comparing it with a 
conventional system. 

Fig. 5 is a diagram for explaining the contents of a 
hierarchical node database. 

Fig. 6 is a diagram for explaining a hierarchical link 
10 table provided for each application program. 

Fig. 7 is a diagram for explaining the relationship of an 
application program, a hierarchical link table and a 
hierarchical node database. 

Fig. 8, which includes Figs. 8A and 8B, is a diagram for 
15 explaining an example wherein the present invention is 
applied for a charge calculation support system for a 
communication company. 

Fig. 9 is a diagram for explaining an example hierarchical 
structure for a discount calculation in Fig. 8. 

20 Fig. 10 is a diagram for explaining an example 

hierarchical structure for a charge totalization process 
in Fig. 8. 
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Fig. 11 is a diagram for explaining an example wherein 
effective period data are set in a hierarchical link 
table, etc. 

Fig. 12, which includes Figs. 12A and 12B, is a diagram 
5 for explaining an example hierarchical link table wherein 
effective period data are set. 

Fig. 13 is a diagram for explaining an example 
variable-length column according to the present invention. 

Fig. 14 is a diagram for explaining an example wherein the 
10 present invention is applied for a drawback calculation 
for a communication company. 

Fig. 15 is a diagram for explaining another example 
wherein the present invention is applied for a charge 
calculation for a communication company. 

15 While the invention will be described in connection with a 
preferred embodiment, the description is not intended to 
limit the invention to that embodiment. On the contrary, 
the invention is intended to cover all alternatives, 
modifications and equivalents as may be included within 

20 the spirit and scope of the invention as described by the 
appended claims. 

DETAILED DESCRIPTION OF THE INVENTION 
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The preferred embodiment of the present invention will now 
be described. In this embodiment, for the sake of 
convenience while presenting the description, a system 
(discounting process) for calculating a charge, such as a 
5 telephone charge, is employed. Further, it should here be 
noted that although in the description of the present 
invention that follows a specific embodiment is used as an 
example, the invention is not limited to this embodiment, 
and can also be applied to other embodiments for which 
10 database systems can be constructed that can flexibly cope 
with alterations. 

Fig. 1 is a block diagram for explaining a data processing 
system according to the present invention. An application 
program 100, for performing a specific operation, receives 

15 from a database system 3 00, via a database management 
system 2 00, data that are required for an application. 
Included in the database system 3 00 of this invention are 
hierarchical link tables 310 that correspond to individual 
application programs 100. The hierarchical link tables 

20 310 are tables in which are stored relationship data 
(pointers, etc.) for databases (entities), i.e., data 
concerning the hierarchical structure of a hierarchical 
node database 320 in which data required for a 
corresponding application program 100 are stored. The 

25 hierarchical node database 32 0 is a database in which, in 
principle, data having no relationship data are stored. 
Although not shown, table data, such as a cycle control 
table that will be described later, are also stored in the 
database 32 0. 
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The data management system using the hierarchical link 
tables 310 of this invention will now be described by 
comparing it with a conventional system, while referring 
to Figs. 2 to 4. 

5 Fig. 2 is a diagram for explaining a conventional 

relationship among databases (entities) . According to the 
hierarchical structure of the databases in this example, 
entity A, block 10, is a parent and entity B, block 12, is 
a child. In this conventional structure, pointer data 
10 that indicate the parent entity A are stored in the data 
record (instance) of entity B. Therefore, when the 
hierarchical structure is changed, the database B must be 
modified. 

Fig. 3 is a diagram for explaining the relationship for 
15 which the hierarchical link table of this invention is 

used. In this example, entities A and B are positioned as 
hierarchical node databases that do not include pointer 
data. The relationship between the two is defined in a 
hierarchical link table X, block 14, in which pointer data 
20 is separately stored. Therefore, even when the 

hierarchical structure is changed, the databases do not 
have to be modified; only the contents of the smaller 
hierarchical link table must be modified. 

Fig. 4 is a diagram for explaining the hierarchical link 
25 table system of the present invention by comparing it with 
the conventional system. In Fig. 4, a specific 
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application program employs a database consisting of six 
entities (actually, their instances) . In the hierarchical 
structure, entity 1, block 21, is positioned as the 
topmost node and entities 2 and 3, blocks 22 and 23, as 
5 child nodes, are positioned at a lower level below it; 
entity 4, block 24, is positioned at a lower level below 
entity 2; and entities 5 and 6, blocks 25 and 26, are 
positioned at a lower level below entity 3, In the center 
position in Fig. 4, the data structure, block 30, used for 

10 the conventional system is shown. Attribute data 31 that 
are the main body of data and pointer data 32 that are 
used to signify the parent-child relationships 
(specifically, to represent the parent entities) are 
stored in the individual data records (data fields) . In 

15 the lowest position in Fig. 4, hierarchical link tables, 
block 40, are shown that are used for the same data 
structure. Here, the pointer data 32, 33 are stored only 
in the data records (data fields) of the hierarchical link 
tables, and attribute data 31 are stored only in the data 

20 records (data fields) of the hierarchical node databases. 

Fig. 5 is a diagram for explaining the contents of the 
hierarchical node database, block 50. The hierarchical 
node database provides a node ID (identifier) 51 for each 
of the entities that are required by all the application 
25 programs, and stores the main body of data 52 as a node 
attribute for each entity. That is, in the hierarchical 
node database, data that can be used in common by the 
application programs are stored as node data in the 
individual data records (data fields) , and each 
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application program can refer to the node IDs via the 
hierarchical link table to specify a required database and 
its hierarchical structure. 

Fig. 6 is a diagram for explaining the hierarchical link 
5 table in which a different data hierarchical structure is 
included for each application program. The hierarchical 
node databases used by application programs are 
represented by "entities" 21, 22, 23, 24, 25 and 26. A 
database used by application program API has a 

10 hierarchical structure wherein entity 1 is the topmost 
node, and entities 2, 5, 4 and 3 are sequentially 
positioned at lower levels. The hierarchical data 
structure for the API is stored using link data 62 for 
links 28 to 31 that represent the relationship of the 

15 entities stored in hierarchical link table Tl, block 60. 
A database used by application program AP2 has a 
hierarchical structure wherein entity 6 is the topmost 
node, and entities 2, 1 and 4 are sequentially positioned 
at lower levels. The hierarchical data structure 

20 associated with the application program AP2 is stored 

using link data 63 for links 32 to 34 that represent the 
relationships of the entities stored in hierarchical link 
table T2, block 61. As is apparent from Fig. 6, a 
hierarchical link table of this invention is prepared and 

25 stored for each application program. 

Fig. 7 is a diagram for explaining the application 
programs, block 70, the hierarchical link table, block 72, 
and hierarchical node databases, blocks 73, 74 and 75. 
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Hierarchical link table A is provided for application 
program A. The relationship data (hierarchical structure 
data) for application program A and effective period data, 
which will be described later, are stored in the 
5 hierarchical link table A. Based on the contents of the 
hierarchical link table A, the application program A 
accesses target hierarchical node databases X, Y and Z to 
obtain required data, and performs a specific operation by 
using the data. 

10 Fig. 8 is a diagram for explaining an example wherein the 
database management system using the hierarchical link 
table of this invention is applied for a charge fee 
support system for a communication company. In this 
example, five application programs (API to APS), blocks 

15 81, 82, 83, 84 and 85, are operated for individual 

clients. Since the hierarchical structure differs for 
each application, a hierarchical link table is defined 
that corresponds to each application program. The 
hierarchical structure can be flexibly changed by altering 

20 the hierarchical link table. It should be noted that a 
different hierarchical structure can be employed (or is 
frequently employed) for each client. Although not shown 
in Fig. 8, each product /service in the contracted basic 
service structure of the application program API is 

25 related not only with a customer at a higher level, but 

also at a lower level in another structure. Some of these 
applications will now be described by using them as 
examples while referring to Figs. 9 and 10. 
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Fig. 9 is a diagram for explaining an example hierarchical 
structure, blocks 91 and 92, for a discount calculation 
program (AP2) in Fig. 8. In this example, the database is 
constructed of seven nodes, as is shown in the product ID 
5 column of hierarchical node database "product catalog" , 
block 93. In Fig. 9, although there are two "attributes 
4," they are included as references merely for convenience 
sake, and it does not mean that the same data are stored 
in both of them. It should be noted that data are stored 

10 in corresponding nodes in the hierarchical node database 
(the same thing applies for Fig. 10) . The hierarchical 
structure of the discount calculation program AP2 in Fig. 
9 is represented as hierarchical link table "discount 
structure 1", block 94. As is apparent from this table, 

15 there are three parent nodes, "charge calculation 4," 
"discount 5" and "discount 6," and corresponding child 
nodes are defined. From the table it can be found that 
the discount 5 is applied only for product/service 1 and 
2, and is not applied for product/service 3 and 4. 

20 Fig. 10 is a diagram for explaining an example 

hierarchical structure, blocks 101 and 102, for the charge 
totalization program (AP4) in Fig. 8. Basically, the same 
explanation can be applied as in Fig. 9, except that 
hierarchical node database "organization DB" is added. 

25 While, for convenience sake, hierarchical node database 
"product catalog" in Fig. 10 is defined as one differing 
from the database in Fig. 9, it may also be the same 
database as in Fig. 9. 
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The database management system using the hierarchical link 
table of this invention has been explained. A database 
management system using "effective period data" will now 
be explained as an even more superior system. 

5 Fig. 11 is a diagram for explaining an example wherein the 
effective period data are stored in the hierarchical link 
table, block 111, or in data records (data fields) in the 
hierarchical node database, block 112. The effective 
period data represents a period during which the table or 

10 each data record in the database is effective relative to 
a corresponding application program. Generally, the date 
whereat the data become effective (effective start date) , 
and the date whereat the data become ineffective 
(effective end date) can be entered as data. In the 

15 hierarchical link table in Fig. 11, for example, link 3 0 
is effective for a period extending from January 10th in 
1999 to March 31st in 1999. When the effective period has 
expired, the parent-child relationship of a parent node 
101 and a child node 103 is also ended. Further, since 

20 link 31 has been effective since April 1st in 1999, the 

parent-child relationship between a parent node 101 and a 
child node 102 is defined as having been effective since 
April 1st. 

In Fig. 11, the effective period data are entered in the 
25 data records of the hierarchical node database. However, 
the effective period data may or may not be entered in the 
hierarchical node database. Generally, since the 
hierarchical node database is accessed in common by 
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various application programs, when an effective date is 
established for all the application programs that access 
the database, or when a plurality of effective dates are 
established for the primary application programs, the 
5 effective period data should also be entered for the 
hierarchical node database. This applies to a case 
wherein the sales of new products are simultaneously begun 
(or stopped) on a specific date* When the effective 
period is to be established only for a specific 
10 application program, only the effective period data in the 
hierarchical link table have to be adjusted, and the data 
do not have to be stored in the hierarchical node 
database . 

Since the application program initiates the process by 
15 examining the effective period data in the table, it does 
not erroneously perform a process that falls outside the 
effective period. When, for example, the application 
program performs a process at intervals corresponding to a 
specific time period (e.g., at the end of each month, a 
20 program totals the records stored during the month) , the 
relationship or the hierarchical structure of a data 
record in the database and another related data record may 
be changed during the month (for example, the parent-child 
relationship or the positional relationship have to be 
25 changed at an instance level, such as in a case wherein 
client A gives a specific telephone number to another 
person B) . While in the conventional system, the 
application program must be run temporarily when an 
alteration is made, in the arrangement of the invention 
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that employs the effective period data, such a process 
need not be performed. 

Fig. 12 includes diagrams (a), (b) , and (c) for explaining 
examples in which the hierarchical link table is employed 
5 when effective period data have been set. In this 

example, the present invention is applied for the charge 
calculation/charge totalization process for the 
communication company described above. Assume that a 
charge is calculated or discounted on 2 6th in the current 

10 month, based on the service usage data (call detail 

records) for a client in a period extending from the 2 0th 
of the previous month to the 19th of the current month 
(the current month in this example is July) . First, while 
referring to diagram (a) of Fig. 12, block 121, an 

15 explanation will be given for the charge 

calculation/discount calculation when there no changes 
occur during the month. In accordance with an instruction 
issued by the cycle control table as needed, on the 26th, 
which is the charge calculation/charge totalization date, 

20 the application program selects all data accumulated 
during a period extending from June 20th to July 19th, 
calculates the charge and the discount, and links the 
results under discount 1. The cycle control table is a 
table (a type of database) wherein, for a series of 

25 applications to be performed at intervals corresponding to 
a specific time period (yearly, quarterly, monthly, weekly 
or daily) , the execution time and the time interval 
(cycle) are entered. If the identifier (also called a 
product ID) of the application program is designated in 

IBM Docket No.: JP9 1999 0204 US1 



24 



such a cycle table, even though not specifically shown, a 
necessary application program can be automatically 
executed by using the hierarchical structure of the 
invention that can be flexibly managed. 

5 The charge calculation/discount calculation when an 

alteration is made during the month will now be described 
while referring to diagram (b) of Fig. 12. In this case, 
assume that a contract based on a previous service 
agreement (discount 1) expired on July 13th, and that a 

10 new contract started on July 14th under a new service 
agreement (discount 2). While referring to the cycle 
control table, generally, the call detail records in a 
period from June 20th to July 19th are selected and the 
charge or discount is calculated. However, since the 

15 effective end date for discount 1, block 122, in the 

hierarchical link table, which represents the relationship 
(contract condition) of telephone 1/telephone 2 is July 
13th, only the charge for the period extending from June 
20 to July 13th is calculated, and the result is linked 

20 under discount 1. For discount 2, block 123, the charge 
is calculated in the same manner for a period extending 
from July 14th to July 19th that is designated by the 
effective period data in the hierarchical link table, 
block 124, and the result is linked under discount 2. 

25 For the charge totalization in diagram (c) of Fig. 12, 
charge 1 (charge totalization program), block 125, can 
examine the data records (discount 1 and 2) in 
hierarchical node database "discount," which is linked 
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below, and can calculate a charge fee merely by adding 
together the results that are linked with these data 
records. Based on the charge obtained, the charging 
process can be performed for company 2, which is a client. 

5 Fig. 13 is a diagram, block 131, showing an example 
variable-length column that improves even more the 
flexibility of the database management system of this 
invention. All or part of the primary hierarchical node 
databases described above can be formed as databases that 

10 have the same records, each of which consists of a 
fixed-length column and a variable-length column. 
Specifically, only data having a size that is always 
constant, e.g., a record identifier (node identifier) and 
effective period data, are stored in the fixed-length 

15 column of each data record, and all the attribute data for 
the pertinent database (entity) are stored in the 
variable-length column. As a result, the records of 
various entities, such as clients, services and 
facilities, can be standardized into a small number of 

20 super types, so that the load imposed by the maintenance 
and the management of a database can be reduced. In Fig. 
13, in order to facilitate the maintenance and the 
management of the equipment database for a communication 
company and to obtain flexibility for performing 

25 alterations, the entity types related to the equipment and 
attribute data are stored in the variable-length column, 
and only the effective period data are stored in the 
fixed-length column. Thus, various entities can be 
included in the same database structure. 
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The merits of the present invention have been explained by 
using several examples, but the invention has another 
merit in that a target for each application process can be 
logically controlled separately and independently. This 
5 will now be described by using several applications in 
Fig. 8, while referring to Figs. 14 and 15. 

Figs. 14A and 14B are diagrams for explaining an example 
wherein the database management system of this invention 
is applied for a drawback calculation, which is one of the 

10 charges applied by a communication company. A drawback 
calculation is a calculation process, during which a fee 
calculated for each client (including a calculated 
discount) is charged, at a rate designated by the client, 
to a charge destination (drawback destination) that is 

15 designated by the client. The hierarchical structure for 
the charge calculation/discount calculation, block 141, in 
Fig. 14A is separated from the hierarchical charge 
structure in Fig. 14B, by defining different hierarchical 
link tables. Based on the charge/discount hierarchical 

20 calculation structure in Fig. 14A, charges are calculated 
in accordance with the various services rendered, while, 
based on the hierarchical charge structure, block 142, in 
Fig. 14B, the fee charged is calculated using a method 
designated by the client. Therefore, the flexibility 

25 required to cope with changes is increased, since, for 

example, the charge destination is designated or changed 
by the client, and the maintenance of each hierarchical 
structure is facilitated. Generally, the charge/discount 
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calculation hierarchical structure in Fig. 14A is 
determined in accordance with the specification of a 
product or service, while the hierarchical charge 
structure in Fig. 14B is determined by the organization or 
5 location of a client. In Fig. 14, the drawback generated 
in the discount calculation is defined as a simple 
proportional allotment, and in the charge totalization 
process, a hierarchical structure for discount 
totalization is prepared separately from the hierarchical 
10 structure for pre-discounted charge totalization. As a 
result, various drawback distribution methods, i.e., 
various proportional allotments (contribution 
allotment ) /equal allotments/special allotments, which are 
requested by the client, can be flexibly employed. 

15 Fig. 15 is a diagram for explaining another example 

wherein the database management system of this invention 
is applied for the application of charges for a 
communication company. In Fig. 15, a charge structure, 
block 151, and a report structure, block 152, are 

20 arbitrarily and independently defined for each client by 
using different hierarchical link tables. The database 
relationship/hierarchical structure used for this charge 
process is also called a group charge structure. 
Conventionally, a group charge structure must be modified 

25 each time a client changes a request, and a great amount 
of labor is required to change many associated databases. 
However, when the database relationship is defined by 
using a hierarchical link table, only this small link 
table must be changed, so that the alteration process can 
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be easily performed. That is, the system of the invention 
that can employ a hierarchical link table to define the 
group charge structure can flexibly cope with a request 
from a client to change the related conditions. 

5 In a charge process (charge 1) for a client, a customer 
"a, " the "charge" application program calculates and adds 
together the charges for services that were provided for 
customer "a" and divisions x, . . . and y at a lower 
level, and transmits a charge to the address of the 

10 customer "a." The "report" application program performs a 
process (report 10) for the pertinent customer, and 
transmits the aggregate (and the specification) of the 
customer "a" and the divisions x, . . . and y to the 
address of the customer "a." For division y, the "report" 

15 application program performs a process (report 11) , and 
reports the aggregate (and the specification) for the 
division y to the address of the division y. 

Advantages of the Invention 

As is described above, according to the database 
20 management system that uses the hierarchical link table of 
the present invention, a database system can be provided 
that can flexibly and quickly cope with an addition or a 
change in the contents of an application or its associated 
data (including data related to services and clients) . In 
25 addition, since the effective period data for this 

invention are included, even when data must be added or 
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changed during a target period, an appropriate retroactive 
process can be quickly and easily performed. 

While the invention has been particularly shown and 
described with reference to a preferred embodiment, it 
5 will be understood that various changes in form and detail 
may be made therein without departing from the spirit and 
scope of the invention. 
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